1. Technical Field
The present disclosure relates to stack traces in debugging and more specifically to enabling more complete stack traces when debugging work items queued for asynchronous execution.
2. Introduction
When developing software, a developer often uses a debugger. A debugger is a software tool or program to test and debug other programs. One common feature of debuggers is the ability to provide a stack trace. A stack trace, also known as a stack backtrace or stack traceback, provides data that is or was available on the active stack or active stack frames at a certain point in time during the execution of a program or at the termination of a program, such as when a program crashes. Stack traces can be extremely useful for developers to learn the cause of a program crash, and to learn the surrounding context of the program crash.
However, as multiprocessor and multithread systems have pervaded desktop, server, and mobile computing, stack traces have been less effective in troubleshooting work items, and in particular work items that are queued for asynchronous execution. When debugging such a work item, a traditional stack trace only shows the context back to the entity that dequeued the work item from the queue. Because of this limitation, much, if not all, of the context surrounding the work item is lost and not available via a stack trace. A developer attempting to debug a program that is crashing during a critical queued work item often has insufficient information to understand the cause of the crash.